Method and system for authenticating an accessory

ABSTRACT

A method, system, and connector interface for authenticating an accessory. the method includes performing a first authentication operation on the accessory by the media player, where an authentication certificate is validated; and performing a second authentication operation on the accessory by the media player, where an authentication signature is validated. According to the system and method disclosed herein, the media player and accessory may utilize a plurality of commands utilized in a variety of environments such as within a connector interface system environment to control access to the media player.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/347,511, filed on Jan. 10, 2010, now U.S. Pat. No. 8,590,036, whichis a continuation of U.S. patent application Ser. No. 11/476,999, filedon Jun. 27, 2006, now U.S. Pat. No. 8,117,651, which are incorporated byreference.

FIELD OF THE INVENTION

The present invention relates generally to electrical devices and moreparticularly to electronic devices such as media players thatcommunicate with accessory devices.

BACKGROUND OF THE INVENTION

A media player stores media assets, such as audio tracks or photos thatcan be played or displayed on the media player. One example of a mediaplayer is the iPod® media player, which is available from Apple Inc. ofCupertino, Calif. Often, a media player acquires its media assets from ahost computer that serves to enable a user to manage media assets. As anexample, the host computer can execute a media management application tomanage media assets. One example of a media management application isiTunes®, version 6.0, produced by Apple Inc.

A media player typically includes one or more connectors or ports thatcan be used to interface to the media player. For example, the connectoror port can enable the media player to couple to a host computer, beinserted into a docking system, or receive an accessory device. Thereare today many different types of accessory devices that caninterconnect to the media player. For example, a remote control can beconnected to the connector or port to allow the user to remotely controlthe media player. As another example, an automobile can include aconnector and the media player can be inserted onto the connector suchthat an automobile media system can interact with the media player,thereby allowing the media content on the media player to be playedwithin the automobile.

Numerous third-parties have developed accessories for use with mediaplayers. An accessory may be used with the media player as long as acompatible connector or port is utilized. Accessories interact with themedia player using an accessory protocol. One example of an accessoryprotocol is referred to as iPod Accessory Protocol (iAP), which isavailable from Apple, Inc. of Cupertino, Calif. The accessory protocolincludes commands which have been typically been made freely accessibleto accessory developers. A problem with the commands being freelyaccessible is that they can be used by unauthorized or counterfeitaccessory devices.

One solution is to perform authentication operations on an accessorydevice. Accordingly, the accessory devices would not have any access tothe media player until after the authentication process is complete.

Thus, there is a need for improved techniques to control the nature andextent to which accessory devices can be utilized with other electronicdevices.

BRIEF SUMMARY OF THE INVENTION

A method, system, and connector interface for authenticating anaccessory are disclosed. The method includes performing a firstauthentication operation on the accessory by the media player, where anauthentication certificate is validated; and performing a secondauthentication operation on the accessory by the media player, where anauthentication signature is validated.

According to the system and method disclosed herein, the media playerand accessory may utilize a plurality of commands in a variety ofenvironments such as within a connector interface system environment tocontrol access to the media player.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B illustrate a docking connector in accordance with thepresent invention.

FIG. 2A is a front and top view of a remote connector in accordance withthe present invention.

FIG. 2B illustrates a plug to be utilized in the remote connector.

FIG. 2C illustrates the plug inserted into the remote connector.

FIG. 3A illustrates the connector pin designations for the dockingconnector.

FIG. 3B illustrates the connection pill designations for the remoteconnector.

FIG. 4A illustrates a typical FireWire connector interface for thedocking connector.

FIG. 4B illustrates a reference schematic diagram for an accessory powersource.

FIG. 4C illustrates a reference schematic diagram for a system fordetecting and identifying accessories for the docking connector.

FIG. 4D is a reference schematic of an electret microphone that may beconnected to the remote connector.

FIG. 5A illustrates a media player coupled to different accessories.

FIG. 5B illustrates the media player coupled to a computer.

FIG. 5C illustrates the media player coupled to a car or home stereosystem.

FIG. 5D illustrates the media player coupled to a dongle thatcommunicates wirelessly with other accessories.

FIG. 5E illustrates the media player coupled to a speaker system.

FIG. 6 is a flow chart, which illustrates a process for controllingaccess to a media player.

FIG. 7 is a flow chart, which illustrates a process for authenticatingan accessory.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates generally to electrical devices and moreparticularly to electrical devices such as media players thatcommunicate with accessory devices. The following description ispresented to enable one of ordinary skill in the art to make and use theinvention and is provided in the context of a patent application and itsrequirements. Various modifications to the preferred embodiment and thegeneric principles and features described herein will be readilyapparent to those skilled in the art. Thus, the present invention is notintended to be limited to the embodiment shown but is to be accorded thewidest scope consistent with the principles and features describedherein.

A method and system in accordance with the present invention areprovided for authenticating an accessory. The method includes performinga first (background) authentication operation on the accessory by themedia player, wherein an authentication certificate is validated. In oneembodiment, the authentication operations are handled in the backgroundsuch that the media player is operative to process commands afterauthentication has begun but before the authentication has completed.This allows the media player and the accessory to interact immediatelyrather than waiting until after the authentication process has completedsuccessfully. The method also includes performing a secondauthentication operation on the accessory by the media player, whereinan authentication signature is validated. In one embodiment, the mediaplayer verifies the authentication signature using a public key providedin the certificate. The media player and accessory may utilize aplurality of commands in a variety of environments to facilitatecontrolling access to the media player. One such environment is within aconnector interface system environment such as described in detailherein below.

Although the authentication of an accessory is described herein below,one of ordinary skill in the art recognizes that the proceduresdescribed below may be applied to the authentication of the media playerand such application would be within the spirit and scope of the presentinvention.

Connector Interface System Overview

To describe the features of the connector interface system in accordancewith the present invention in more detail, refer now to the followingdescription in conjunction with the accompanying drawings.

Docking Connector

FIGS. 1A and 1B illustrate a docking connector 100 in accordance withthe present invention. Referring first to FIG. 1A, the keying features102 are of a custom length 104. In addition, a specific key arrangementis used where one set of keys is separated by one length at the bottomof the connector and another set of keys is separated by another lengthat the top of the connector. The use of this key arrangement preventsnoncompliant connectors from being plugged in and causing potentialdamage to the device. The connector for power utilizes a Firewirespecification for power. The connector includes a first make/last breakcontact to implement this scheme. FIG. 1B illustrates the firstmake/last break contact 202 and also illustrates a ground pin and apower pin related to providing an appropriate first make/last breakcontact. In this example, the ground pin 204 is longer than the powerpin 206. Therefore, the ground pin 204 would contact its mating pin inthe docking accessory before the power pin 206, minimizing internalelectrical damage of the electronics of the device.

In addition, a connector interface system in accordance with the presentinvention uses universal serial bus (USB), universal asynchronousreceiver-transmitter (UART), and Firewire interfaces as part of the samedocking connector alignment, thereby making the design more compatiblewith different types of interfaces, as will be discussed in detailhereinafter. In so doing, more remote accessories can interface with themedia player.

Remote Connector

The connection interface system also includes a remote connector whichprovides for the ability to output and input audio, provides I/O serialprotocol, and provides an output for video. FIG. 2A is a front and topview of a remote connector 200 in accordance with the present invention.As is seen, the remote connector 200 includes a top headphone receptacle202, as well as a second receptacle 204 for remote devices. FIG. 2Billustrates a plug 300 to be utilized in the remote connector. The plug300 allows the functions to be provided via the remote connector. FIG.2C illustrates the plug 300 inserted into the remote connector 200.Heretofore, all of these features have not been implemented in a remoteconnector. Therefore, a standard headphone cable can be plugged in, butalso special remote control cables, microphone cables, and video cablescould be utilized with the remote connector.

To describe the features of the connector interface system in moredetail, please find below a functional description of the dockingconnector, remote connector and a command set in accordance with thepresent invention.

Docking and Remote Connector Specifications

For an example of the connector pin designations for both the dockingconnector and for the remote connector for a media player such as aniPod® device by Apple, Inc., refer now to FIGS. 3A and 3B. FIG. 3Aillustrates the connector pin designations for the docking connector.FIG. 3B illustrates the connection pin designations for the remoteconnector.

Docking Connector Specifications

FIG. 4A illustrates a typical Firewire connector interface for thedocking connector. The following are some exemplary specifications:Firewire power (8V-30V DC IN, 10 W Max). In one embodiment, Firewire maybe designed to the IEEE 1394 A Spec (400 Mb/s).

USB Interface

The media player provides two configurations, or modes, of USB deviceoperation: mass storage and media player USB Interface (MPUI). The MPUIallows the media player to be controlled using a media player accessoryprotocol (MPAP) which will be described in detail later herein, using aUSB Human Interface Device (HID) interface as a transport mechanism.

Accessory 3.3 V Power

FIG. 4B illustrates the accessory power source. The media playeraccessory power pin supplies voltages, for example, 3.0 V to 3.3V+/−5%(2.85 V to 3.465 V) over the 30-pin docking connector and remoteconnector (if present). A maximum current is shared between the 30-pindocking and Audio/Remote connectors.

By default, the media player supplies a particular current such as 5 mA.Proper software accessory detection is required to turn on high power(for example, up to 100 mA) during active device usage. When devices areinactive, they must consume less than a predetermined amount of powersuch as 5 mA current.

Accessory power is grounded through the Digital GND pins.

FIG. 4C illustrates a reference schematic diagram for a system fordetecting and identifying accessories for the docking connector. Thesystem comprises a resistor to ground that allows the device todetermine what has been plugged into the docking connector. There is aninternal pull-up on Accessory Identify within the media player. Two pinsare required (Accessory Identify & Accessory Detect).

FIG. 4D is a reference schematic of an electret microphone that may beconnected to the remote connector.

Serial Protocol Communication:

a) Two pins used to communicate to and from device (Rx & Tx)

b) Input & Output (OV=Low, 3.3V=High)

As mentioned previously, media players connect to a variety ofaccessories. FIGS. 5A-5E illustrate a media player 500 coupled todifferent accessories. FIG. 5A illustrates a media player 500 coupled toa docking station 502. FIG. 513 illustrates the media player 500′coupled to a computer 504. FIG. 5C illustrates the media player 500″coupled to a car or home stereo system 506. FIG. 5D illustrates themedia player 500′″ coupled to a dongle 508 that communicates wirelesslywith other devices. FIG. 5E illustrates the media player 500″″ coupledto a speaker system 510. As is seen, what is meant by accessoriesincludes but is not limited to docking stations, chargers, car stereos,microphones, home stereos, computers, speakers, and accessories whichcommunicate wirelessly with other accessories.

As mentioned previously, this connector interface system could beutilized with a command set for authenticating an accessory. In oneembodiment, the accessory may be a host computer or any other electronicdevice or system that may communicate with the media player. It shouldbe understood by one of ordinary skill in the art that although theabove-identified connector interface system could be utilized with thecommand set, a variety of other connectors or systems could be utilizedand they would be within the spirit and scope of the present invention.

As described above, accessories interact with the media player using amedia player accessory protocol. An example of such a media playeraccessory protocol is the iPod Accessory Protocol (iAP). The mediaplayer accessory protocol refers to the software component executing onthe media player that communicates with accessories over a giventransport layer. The application of the media player may be, forexample, a media player application framework that presentsmenus/screens to the user. Media player commands are associated with theprocessing of voice, video, and other data between the media player andthe accessory. For example, commands may be associated with readoperations and write operations to transfer and store informationbetween the media player and the accessory. Accordingly, in oneembodiment, for each command related to the media player, there is areciprocal command for the accessory. In one embodiment, commands may begrouped and associated with specific accessory functionality.

Command Functionality

Although a plurality of commands is described herein below, one ofordinary skill in the art recognizes that many other commands could beutilized and their use would be within the spirit and scope of thepresent invention. Accordingly, the list of commands below isrepresentative, but not exhaustive, of the types of commands that couldbe utilized to authenticate an accessory. Furthermore, it is alsoreadily understood by one of ordinary skill in the art that a subset ofthese commands could be utilized by a media player or an accessory andthat use would be within the spirit and scope of the present invention.A description of the functionality of some of these commands isdescribed below.

Authentication of an Accessory

In previous authentication methods, the accessory transmits anidentification message to the media player, where the identificationmessage indicates that the accessory supports certain commands andsupports authentication. The media player then transmits anacknowledgment message to the accessory. The media player then blocksaccess by the accessory until the entire authentication processcompletes. The media player may display a “Connecting . . . ” screen.The media player then confirms that the authentication version numberthat the accessory provides is the correct version number. If so, themedia player transmits a challenge to be signed by the device. The mediaplayer then validates the authentication signature using a public keybased on a device ID from the accessory. The following describesimprovements over the previous authentication methods, in accordancewith the present invention.

FIG. 6 is a flow chart, which illustrates a process for controllingaccess to a media player, in accordance with the present invention. AsFIG. 6 illustrates, the process begins in step 602 where the mediaplayer performs a background authentication operation on the accessory,where the authentication certificate is validated. More specifically,during the background authentication operation, the accessory transmitsauthentication information to the media player, and the media playerreceives and then validates the certificate contained in theauthentication information. In one embodiment, the authenticationinformation may also include an authentication version number.Authentication certificates are described in more detail below. Asdescribed in more detail below, the media player does not wait until theentire authentication process completes but instead allows certainaccess before the authentication process completes. Next, in step 604,the media player performs a second authentication operation on theaccessory, where an authentication signature is validated. Morespecifically, during the second authentication operation, the accessorytransmits an authentication signature to the media player, and the mediaplayer receives and then validates the authentication signature. In oneembodiment, the media player verifies the authentication signature usinga public key. More detailed embodiments of the background authenticationand second authentication operations are described below and shown inFIG. 7.

Although the authentication of an accessory is described herein, one ofordinary skill in the art recognizes that the procedures describedherein may be applied to the authentication of the media player, andsuch applications would be within the spirit and scope of the presentinvention. For example, the same or similar steps described in FIG. 6above and/or in FIG. 7 below may be utilized by an accessory toauthenticate the media player.

Authentication Certificates

Standard authentication certificates function as containers for datasuch as the certificate creator (issuer, country, etc.), certificatetype, valid certificate date ranges, and other metadata. Authenticationcertificates, also referred to as certificates or certs, are generatedand signed by one or more certificate authorities (CAs) and have aunique serial number. In one embodiment, the certificate may be storedin an authentication coprocessor chip on the accessory. Authenticationcertificates in accordance with the present invention contain not onlythe metadata as in a standard authentication certificate but also deviceclass information and a public key, which are described in more detailbelow.

As described in more detail below, the media player verifiescertificates using a public key that is issued by the CA. The mediaplayer may also use the public key to verify a signed challenge.Certificates are used to transfer the public key and otheraccessory-specific information to the media player. Suchaccessory-specific information may contain, for example, device classinformation about the accessory. The device class determines whatcommands the accessory is permitted to use with respect to the mediaplayer. In one embodiment, the media player may add permissible commandsto existing classes or add new device classes by means of a media playerfirmware update. New accessories may be supported by the media playerwhen the CA issues new certificates to the accessory vendor.

In one embodiment, if a certificate is somehow compromised and cloned incounterfeit devices, the compromised serial number may be added to acertificate revocation list (or CRL) on the media player to preventdevices using the certificate from authenticating successfully. If thecertificate parser of the media player does not recognize the cert'sdevice class, the media player will reject the certificate. In oneembodiment, a certificate to be used for device authentication may havea preset lifespan (e.g., in the range of 1-5 years, etc.), which may beset, for example, by a date. In one embodiment, certificate expirationcould be accomplished by adding device serial numbers to the CRL afterthe expiration date has passed.

FIG. 7 is a flow chart, which illustrates a process for authenticatingan accessory, in accordance with the present invention. As FIG. 7illustrates, the process begins in step 702 where the media player andaccessory exchange messages to determine whether the accessory supportscertain commands and supports immediate authentication. Morespecifically, in one embodiment, the accessory transmits anidentification message to the media player. The identification messageincludes a device identification (ID) and an indication that theaccessory supports certain commands and supports authentication. In apreferred embodiment, support for immediate authentication is required.The media player then transmits an acknowledgment message to theaccessory. In one embodiment, the media player notifies the applicationof the media player that the accessory is attempting to access the mediaplayer.

As described above, in one embodiment, the authentication operations arehandled in the background to allow multiple cryptography options (e.g.,RSA or SFEE) with/without hardware acceleration to be used. As a result,the media player is operative to process device commands afterauthentication has begun, before the authentication has completed, andthrough its successful completion. When device authentication fails(e.g., retry count and/or maximum time has been exhausted), the mediaplayer could lockout processing of incoming commands and prevent thedevice from interacting with media player. Media player applicationswill need to permit non-risky device use once authentication hasstarted. Risky behavior is defined as anything that could permanentlyalter the media player behavior or download unsafe media. Examples ofrisky behavior to be avoided could be downloading executable media, orfirmware updates. If authentication fails at some later point, theapplication of the media player could cancel any device-relatedactivities and possibly report an error to the user (e.g., “Device isnot supported”).

Referring still to FIG. 7, in step 704, during the backgroundauthentication operation, the media player transmits an authenticationinformation request to the accessory. In one embodiment, the mediaplayer starts a timeout timer. Next, in step 706, the accessorytransmits the authentication information to the media player. In oneembodiment, the authentication information includes an authenticationmajor version, an authentication minor version, and a publiccertificate, where the certificate may be divided up into sections if itis large (e.g., greater than 500 bytes). If the certificate is dividedup into sections, upon receipt of the authentication information, themedia player reassembles the certificate. When the certificate is fullyassembled, the certificate is parsed for device class information. Themedia player then converts a class number from the device classinformation into an allowed command mask. This mask is used to validatethat the commands identified by the device are allowed by thecertificate. In other words, the media player validates the certificatebased at least in part on the device class information.

Next, in step 708, the media player validates the authenticationinformation. The authentication information may be invalid for a numberof reasons. For example, the authentication information may be invalidif the authentication version is not valid, if the public certificatehas expired or is on the certificate revocation list (CRL). If any ofthe authentication information is invalid, the background authenticationoperation fails. A failure will restart the authentication process (if aretry count and timeout limits have not been exceeded). The backgroundauthentication operation passes if the authentication version isvalidated and if the certificate class commands have been determined tomatch or exceed those requested by an identify command of the mediaplayer, and if a certification chain has been verified. In oneembodiment, non-risky media player command application functions andcommand processing are enabled while authentication process continues.In one embodiment, the media player may transmit a message to theaccessory indicating a version information status.

Next, in step 710, during a second authentication operation, the mediaplayer transmits an authentication signature request to the accessory.The authentication signature request includes a random nonce/challengeto be signed by the device. The specific nonce/challenge length may varyand will depend on the specific implementation. Next, in step 712, theaccessory transmits an authentication signature (i.e., a message with asigned challenge/signature) to the media player. Next, in step 714, uponreceipt of the authentication signature, the media player validates theauthentication signature (i.e., the signed challenge). In oneembodiment, the media player verifies the signed nonce/challenge using apublic key based on a device ID from the accessory. In a preferredembodiment, the media player verifies the signed nonce/challenge using apublic key from the certificate provided by the accessory.

In one embodiment, an accessory authentication process (AAP) is based ona public key/private key system where the accessory has a private keyand the media player has the associated public key. The accessoryauthentication process is closely integrated with accessory protocolcommands.

Before completing the authentication process, the media player transmitsan authentication status message to the accessory indicating signaturestatus and authentication process completion. The authentication passesif the media player verifies the authentication signature. Otherwise,the authentication process fails. If authentication passes, theapplication of the media player unblocks to allow user access to thedevice.

If the authentication process fails, the device port of the media playerwill lock out the accessory. Also, upon a failure, the media playerde-authorizes the accessory to prevent the accessory from utilizing themedia player resources. In one embodiment, the media player may alsotransmit an authentication status to the application of the mediaplayer. For example, if the authentication fails, the application of themedia player may display a “Connection Failed” message.

In one embodiment, the authentication operations may utilize a retrycount and maximum timeout. Accordingly, in one embodiment, theauthentication can also fail if the retry counter or maximum timeout isexceeded. Locking out a port prevents an accessory from simulating adetach or re-identifying in order to reset the authenticationretry/timeout counters. In one embodiment, incoming packets may bedeleted if a device port authentication state is set to “lockout.” Thiswill prevent any locked out device packets from being processed. In oneembodiment, if the failure is due to an accessory identifying morecommands than allowed by the certificate, the device lockout will not beactivated at authentication failure and the accessory may be permittedto re-identify.

A method, system, and connector interface for authenticating anaccessory has been disclosed. The method includes performing a firstauthentication operation on the accessory by the media player, where anauthentication certificate is validated. The method also includesperforming a second authentication operation on the accessory by themedia player, where an authentication signature is validated. Accordingto the system and method disclosed herein, the media player andaccessory may utilize a plurality of commands in a variety ofenvironments such as within a connector interface system environment tocontrol access to the media player.

Although the present invention has been described in accordance with theembodiments shown, one of ordinary skill in the art will readilyrecognize that there could be variations to the embodiments and thosevariations would be within the spirit and scope of the presentinvention. For example, the present invention can be implemented usinghardware, software, a computer readable medium containing programinstructions, or a combination thereof. Software written according tothe present invention is to be either stored in some form ofcomputer-readable medium such as memory or CD-ROM, or is to betransmitted over a network, and is to be executed by a processor.Consequently, a computer-readable medium is intended to include acomputer readable signal, which may be, for example, transmitted over anetwork. Accordingly, many modifications may be made by one of ordinaryskill in the art without departing from the spirit and scope of theappended claims.

What is claimed is:
 1. A media player comprising: a processor; and anaccessory interface coupled to the processor and configured tocommunicate with an accessory according to a media player accessoryprotocol that defines a plurality of application commands to invoke aplurality of media player application functions, wherein the processorin conjunction with the accessory interface is configured to: initiatean authentication operation to authenticate the accessory; receive firstauthentication information from the accessory; validate the firstauthentication information; receive one of the plurality of applicationcommands of the media player accessory protocol from the accessory basedon validation of the first authentication information; in response tothe received application command, invoke one of the plurality of mediaplayer application functions; receive second authentication informationfrom the accessory, the second authentication information beingdifferent from the first authentication information; validate the secondauthentication information to determine that authentication operationcompleted successfully; and receive a subsequent one of the plurality ofapplication commands from the accessory and, in response to thesubsequent application command, invoke a subsequent one of the pluralityof media player application functions.
 2. The media player of claim 1wherein the processor is further configured to ignore any subsequentapplication command received from the accessory if the authenticationoperation fails.
 3. The media player of claim 1 wherein the firstauthentication information includes one or more of: an authenticationcertificate, an authentication major version information, and anauthentication minor version information.
 4. The media player of claim 3wherein the processor is further configured to: receive a deviceidentification message from the accessory, the device identificationmessage including an indication of a command set supported by theaccessory, the supported command set including at least some of theplurality of commands defined by the media player accessory protocol;determine an allowed command set for the accessory based on theauthentication information included in the authentication certificate;and compare the allowed command set to the supported command set,wherein the authentication operation fails in the event that the allowedcommand set does not match the supported command set.
 5. The mediaplayer of claim 3 wherein the second authentication informationcomprises a digital signature that includes a digitally signed versionof a random challenge transmitted to the accessory by the media player.6. The media player of claim 5 wherein the digitally signed version ofthe random challenge is signed by the accessory using a private key andwherein the processor is configured to: extract a public key from theauthentication certificate; and use the public key to validate thedigital signature.
 7. The media player of claim 1 wherein the processoris further configured to: receive a device identification message fromthe accessory, the device identification message including an indicationof a command set supported by the accessory, the command set includingat least some of the plurality of commands defined by the media playeraccessory protocol, wherein during the authentication operation, one ofthe plurality of application commands is one of the commands in thecommand set supported by the accessory.
 8. The media player of claim 1wherein the processor is further configured to: receive a deviceidentification message from the accessory, the device identificationmessage including an indication of a command set supported by theaccessory, the command set including at least some of the plurality ofcommands defined by the media player accessory protocol, wherein thecommand set includes a first command that relates to a risky behaviorand a second command that relates to a non risky behavior, wherein ifthe second command is received prior to validation of the secondauthentication information, the media player invokes a correspondingmedia player application function but if the first command is receivedprior to validation of the second authentication information, the mediaplayer ignores the first command.
 9. The media player of claim 1 whereinin the event that an error occurs during the authentication operation,the processor is configured to retry the authentication operation if atimeout period has not ended.
 10. The media player of claim 9 whereinthe processor is further configured to update a count of retries andwherein the authentication operation fails in the event that the countof retries exceeds a retry limit.
 11. The media player of claim 1wherein if the authentication operation fails, the processor isconfigured to provide a notification to a user of the media player, andwherein the notification includes a message displayed on a displayscreen of the media player.
 12. A media player comprising: a processor;and an accessory interface coupled to the processor and configured tocommunicate with an accessory according to a media player accessoryprotocol that defines a plurality of application commands to invoke aplurality of media player application functions, the plurality of mediaplayer application functions including a first function associated witha risky behavior and a second function associated with a non-riskybehavior, wherein the processor is configured to: receive firstauthentication information from the accessory in response to anauthentication request, the first authentication information beingusable by the media player in the authentication operation; receive atleast one of the plurality of application commands from the accessoryprior to completion of the authentication operation based on validationof the first authentication information; in response to the at least oneapplication command, invoke an associated one of the plurality of mediaplayer application functions if the associated one of the plurality ofmedia player application functions is the second function but not invokethe associated one of the plurality of media player applicationfunctions if the associated one of the plurality of media playerapplication functions is the first function; and receive anauthentication signature from the accessory for validation, wherein theauthentication operation completes upon validation of the authenticationsignature, the authentication signature being different from the firstauthentication information.
 13. The media player of claim 12 wherein ifthe authentication operation fails, the processor is configured toignore any subsequent commands received from the accessory.
 14. Themedia player of claim 12 wherein the plurality of media playerapplication functions include a function associated with processing atleast one of: voice data, video data, or other data.
 15. The mediaplayer of claim 12 wherein the first function is a function related todownloading executable media onto the media player.
 16. The media playerof claim 12 wherein the first function is a function related toperforming a firmware update on the media player.
 17. An accessorycomprising: a controller; and a media player interface coupled to thecontroller and configured to communicate with a media player accordingto a media player accessory protocol that defines a plurality ofapplication commands to invoke a plurality of media player applicationfunctions, wherein the controller is configured to: receive anauthentication request from the media player, the authentication requestinitiating an authentication operation; transmit first authenticationinformation to the media player in response to the authenticationrequest, send at least one of the plurality of application commands tothe media player based on validation of the first authenticationinformation and prior to completion of the authentication operation,wherein the media player processes the at least one application command,thereby allowing the accessory to invoke at least one of the pluralityof media player application functions during the authenticationoperation; and transmit second authentication information different fromthe first authentication information to the media player for validation,wherein the authentication operation completes upon validation of thesecond authentication information, and wherein if the authenticationoperation fails, any subsequent application commands sent by theaccessory are not processed by the media player.
 18. The accessory ofclaim 17 wherein the application commands defined by the media playeraccessory protocol includes commands to transfer and store informationbetween the media player and the accessory.
 19. The accessory of claim17 wherein the application commands defined by the media playeraccessory protocol includes a command associated with processing of atleast one of voice, video, or other data between the media player andthe accessory.
 20. An accessory comprising: a controller; and a mediaplayer interface coupled to the controller and configured to communicatewith a media player according to a media player accessory protocol thatdefines a plurality of application commands to invoke a plurality ofmedia player application functions, the plurality of media playerapplication functions including a first function associated with a riskybehavior and a second function associated with a non-risky behavior,wherein the controller is configured to: receive an authenticationrequest from the media player, the authentication request initiating anauthentication operation; send first authentication information to themedia player in response to the authentication request, the firstauthentication information being usable by the media player in theauthentication operation; send at least one of the plurality ofapplication commands to the media player prior to completion of theauthentication operation based on validation of the first authenticationinformation, wherein in response to the at least one applicationcommand, the media player invokes an associated one of the plurality ofmedia player application functions if the associated one of theplurality of media player application functions is the second functionbut does not invoke the associated one of the plurality of media playerapplication functions if the associated one of the plurality of mediaplayer application functions is the first function; send anauthentication signature to the media player for validation, wherein theauthentication operation completes upon validation of the authenticationsignature, the authentication signature being different from the firstauthentication information; and wherein if the authentication operationfails, any subsequent commands sent by the accessory are ignored by themedia player.
 21. The accessory of claim 20 wherein the plurality ofmedia player application functions include a function to transfer andstore information between the media player and the accessory.
 22. Theaccessory of claim 20 wherein the first function is a function relatedto downloading executable media onto the media player.
 23. The accessoryof claim 20 wherein the first function is a function related toperforming a firmware update on the media player.
 24. The accessory ofclaim 20 wherein the media player application functions includefunctions associated with the processing of voice, video, and other databetween the media player and the accessory.
 25. The accessory of claim20 wherein after completion of the authentication operation, thecontroller is configured to send a subsequent application command toinvoke the first function, wherein if the authentication operationcompleted successfully, the media player invokes the first function inresponse to the subsequent application command.